The present invention relates to computing, and in particular, to a systems and methods for a model-driven database query, that allows a development/design-time tool to permit the developer to create the query based upon business objects and their associations.
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Databases are highly useful tools allowing users to manage complex relationships between different types of data. FIG. 1 shows a highly simplified view of a system 100 comprising a human user 102 who is in communication with a database 104 through an intervening user interface (UI) 106. When a large volume of data is requested to be read and returned from the database 104, in general the UI 106 will formulate and pose a query 108 having features 109, to the database.
FIG. 2A shows an example of a screen shot 200 of a user interface posing such a query. In particular, the location of the arrow cursor 202 indicates the user to be seeking a list of existing account names in a window 204 devoted to responding to potential new business opportunities.
FIG. 2B shows the information 206 returned from the database as a result of this query. This information 206 includes data fields relating to a plurality of existing accounts 208. The data fields include the name 210 of the existing account, the identifier (ID) 212 of the existing account, and the location (city) 214 of the existing account.
As shown in FIGS. 2C-2G, the query has a number of features allowing manipulation of the data that has been read from the database. For example, FIG. 2C shows a sorting feature allowing the user to manipulate the returned data by a field type, here the Account ID 212.
FIG. 2D shows yet another query feature, that of paging. This query feature governs the manner in which the returned data is displayed to a user by the user interface. Typically, returned data is restricted to a ‘page’ to be shown to the user, instead of returning all data, which would be inefficient. Here, the paging feature has displayed only rows 115-124 out of a total of 274 rows that were responsive to the query.
FIG. 2E shows the query feature of selection. This query feature allows a user to identify portions of the returned data corresponding to selected input within a particular field, here accounts having ‘Silver’ in the account name field 210. The query feature of selection also allows ranges of values, and selection in the positive (Including) or the negative (Excluding).
FIG. 2F shows the query feature of search. This query feature allows a user to identify portions of the returned data corresponding a search term, here any field containing the term “mc”.
FIG. 2G shows the query feature of filtering. Filtering is similar to the query feature of selection, but is more limited in application. In particular, filtering restricts the display of rows and columns already returned by searching, to those having the filter values.
Conventionally, it may be challenging to design a user interface that is able to interact in an effective and efficient manner with the underlying database. One reason for this is the large number of intervening layers actually present between the UI and the underlying data of the database.
FIG. 3 depicts an example of such a multi-layer architecture 300, showing the various layers 302, 304, 306, 308, and 310 that are implicated in a query from the user seeking to read data from the database. A single, individual software developer may be familiar with the structure/language of fewer than the full complement of these layers. Accordingly, multiple developers and tools are typically required to create an effective UI, and particularly to create a UI capable of posing queries that are efficiently processed by the various layers.
For example, FIG. 1 shows the creation of query structure 110 having the features 109, utilizing a model 112 of database-level concepts such as tables, logical grouped tables, modeled relationships between tables, views, joins, indexes, and restriction rules/constraints. In order to function effectively, however, such a query structure may also need to consider the structure and attributes of intervening levels, thereby complicating development efforts.
The present disclosure addresses these and other issues with systems and methods for a model-driven database query that allows a development/design-time tool to permit the developer to create a query based upon business objects and their associations.